Secure communication sessions across a network are known. For example, Secure Socket Layer (SSL) techniques and Transport Layer Security (TLS) techniques are known. The network may be the Internet, Intranets, and other forms of both public and private networks. While secure communications provide security in the forms of confidentiality, integrity, and authentication, it also has the effect of obscuring the native (i.e., non-encrypted) content from inspection by other devices on a network intended to provide security services, such as a Next-Gen Firewall (NGFW), Deep Packet Inspection (DPI) engine, Intrusion Prevention System (IPS), advanced threat/malware analysis engine, full packet capture, or any other form of security analytics.
To address this inhibitive side-effect, a number of solutions have become available to perform various types of decryption of secure communication traffic for the purpose of restoring visibility. Some of these implementations are designed to perform the decryption and inspection within a single physical or virtual machine, allowing for the decrypted traffic to remain within the cryptographic boundary of the machine/appliance. Other implementations may involve multiple security devices working together in a physically secure environment and connected by direct interfaces. While this protects against exposure of the decrypted traffic to relatively trivial eavesdropping/tampering attempts enabled by the physical traversal across a network, it precludes the availability of the decrypted traffic for inspection, collection, consumption, or other kinds of use by external security platforms that are not directly connected.
To enable the availability of decrypted traffic for general external inspection, collection, and the like, a class of SSL decryption solution or “visibility appliance” was invented, which allows for the sharing of forms of the decrypted traffic via one or more methods. Known implementations employ emission of the decrypted content in the form of reconstituted TCP sessions via physical or virtual network interfaces, but other methods of sharing might include non-sessionized datagrams containing content payloads, or access to shared memory or storage. While this solution allows for shared access, it creates security risks while the decrypted data is in motion across a network, or while it is at rest in any kind of persistent repository, such as a full packet capture or security analytics platform.
FIG. 1 illustrates a prior art system. The system includes a client and a directly connected visibility appliance 102. The visibility appliance 102 is connected to a network 106, which may be any combination of wired and/or wireless networks. The network 106 provides connectivity to a server 110. The visibility appliance 102 is also connected to a security appliance 108 (either directly, through network 106 or through some other network).
The client 100 initiates a first session with a first key 112. The visibility appliance 102 intercepts the first session 114 and initiates its own SSL session (as a client) to the server 110. That is, it initiates a second session with a second key 116. The second key is negotiated between the visibility appliance 102 and the server 110. The visibility appliance 102 then completes the session with the client 100 using the first key.
Having access to both the client-side and server-side session keys, the visibility appliance 102 is then able to send the combined decrypted data to the external security appliance 108, as well as, optionally, any/all non-SSL traffic that it might be bridging. That is, the visibility appliance 102 decrypts the session and routes it 120 to the security appliance 108, which stores the decrypted data 122.
In another implementation, the visibility appliance 102 can behave as a transparent proxy. The visibility appliance 102 detects the session initiation and allows the client 100 and server 110 to negotiate the session details. The visibility appliance 102 only intervenes in the SSL Handshake in order to manipulate the SSL server certificate and to participate in the negotiation of the session keys. The choice of cipher suite and key sizes used is between the client 100 and server 110 and will always be the same for the first session and the second session.
In situations where the security appliance 108 provides some kind of persistent store of the decrypted data (e.g., a full packet capture or security analytics platform), there is a data-at-rest problem of transparency. It is worth noting that techniques such as encrypted volumes or full disk encryption (FDE) only partially address the problem because the data, unless otherwise transformed by the security appliance 108 itself, remains accessible to anyone with access to the operating system or application that provides access to the data, thus potentially exposing Personally Identifiable Information (PII), Private Health Information (PHI) or other types of confidential or private information.
In view of the foregoing, techniques are needed for on-demand decryption of secure communication sessions.